Comment utiliser le Framework en DDD puis en TDD (DomainAndTestDrivenDevelopment)
Tout d’abord, il faut comprendre ce qu'est le Domain Driven Development:
Il s'agit d'encapsuler toutes les methodes du domaine métier sur lequel l'application porte dans des classe avec leurs propres composants, contrat ou implémentation,. Pour cela il faut avoir des notions de programmation objet en PHP
Pourquoi utiliser DDD ? ✅
- Quand l’application est techniquement complexe ou que son métier l’est
- S’il y a un haut risque financier dans le métier
- S'il y a une grosse valeur dans le métier
Pourquoi ne pas utiliser DDD ? ❌
- Un simple CRUD
- S’il s’agit de gérer du contenu (CMS & Cie)
- Pas ou peu de maintenance, de besoin d’évolution
- Une application techniquement simple
- Un domaine très générique ou peu de complexité métier
- « Time To Market » rapide (il faut livrer rapidement)
- Une équipe de développeurs trop jeunes
A partir du moment où l'on encapsule les méthode métier : alors l'ont peut les rationnaliser avec des tests unitaires et ainsi faire du TDD (TestDrivenDevelopment).
Pourquoi utiliser TDD ? ✅
- Guidage du développeur
- Réponse stricte au besoin (moins d’entropie logicielle)
- Complexité minimale
- Filet de sécurité contre les régressions,
- Meilleure qualité et moins de dette technique.
- Documentation du code
- Les projets TDD ont 70% moins d’anomalies que les projets classiques.
Pourquoi ne pas utiliser DDD ? ❌
- Pour les projets TDD le développement initial est 25% plus long
- Le client paye pour de la fonctionnalité pas pour des tests. Il se dit que c’est le job des IT de lui livrer un logiciel sans bug et de qualité.
- Justifier un prix 25% plus cher ou des délais 25% plus longs pour écrire du test c’est souvent très compliqué.
Avec SAND il est simple de structurer ces domaines car les dossiers test et domain sont là pour vous encourager à le réaliser.
Donc n'hésitez pas lorsque vous créerez votre première application a définir les classe de domaines sur lesquelles porte votre application car ce sont celles que vous garderez pour d'autres backend de vos applications.
Celles ci bien que vous pouvez assimiler les dépendance Composer sont le code source qui provient de vos méninges.
N'oubliez qu'il n'est pas nécessaire de réinventer la roue mais que parfois cela permet de faire de bien jolies choses.